來到第二天啦
昨天我們說了 Kubernetes 是用來管理 Container。

但如果連 Container 為什麼出現都沒有真正理解，學 Kubernetes 就很容易淪為變成一堆抽象名詞。

所以今天先往回走。

最早的部署方式：一台 Server 跑很多服務

假設公司買了一台 Server：

Physical Server
│
├── Nginx
├── Java API
├── Python API
└── MySQL

看起來很合理。

問題是每個程式共用同一套：

Operating System
Library
CPU
Memory
Filesystem

假設：

Service A
需要 Python 3.10

但是：

Service B
只能跑 Python 3.8

環境開始衝突。

另一個問題是資源隔離。

某個程式突然 Memory Leak：

Service A
████████████████ RAM

Service B
沒 RAM 可以用

大家都住在同一台 OS 裡，一個人搞事可能拖累所有人。

於是...

VM 出現了

Virtual Machine 的想法是：

Physical Machine
        │
      Hypervisor
        │
 ┌──────┼──────┐
 ▼      ▼      ▼
VM1    VM2    VM3

每一台 VM 都有：

Guest OS
Application
Library

隔離效果非常好。

但是代價也很明顯。

假設每台 VM 光 Operating System 就吃：

1～2 GB RAM

如果我們只是想跑一個 100 MB 的小 API，卻要替它準備完整 OS，成本並不低。

Container 做了什麼？

Container 沒有替每個 Application 啟動完整 Guest OS。

大概可以理解成：

Physical Machine
       │
     Host OS
       │
 Container Runtime
       │
 ┌─────┼─────┐
 ▼     ▼     ▼
App A App B App C

不同 Container 共享 Host Kernel，但 Application 的：

Filesystem
Process
Network
Dependency

可以被隔離。

所以比 VM：

更輕量
啟動更快
更容易大量建立

Docker Image 和 Container 不一樣

這是新手第一個一定要分清楚的地方。

假設：

Image

是一份蛋糕模具。

Container 是：

真的用這個模具做出來的蛋糕。

例如：

docker pull nginx

取得的是：

nginx Image

執行：

docker run nginx

才產生：

Container

同一個 Image 可以建立：

Container 1
Container 2
Container 3

所以：

Image
＝ Template

Container
＝ Runtime Instance

這個觀念之後會直接延伸成 Kubernetes：

Pod
↓
Container
↓
Image

Docker 已經很好用了，為什麼還要 Kubernetes？

我們假設目前：

docker run api
docker run redis
docker run postgres

三個 Container 都起來。

小型專案完全沒問題。

但假設系統變成：

20 個 API
5 個 Worker
3 個 Redis
6 個其他 Service

這時候問題來了。

API Container #7 掛掉：

誰重新建立？

Server A 掛掉：

哪些 Container 要搬到 Server B？

流量增加：

誰幫 API 從 20 個變 50 個？

新版 API 上線：

怎麼一次只換一部分？

IP 一直改：

Service 之間怎麼找到彼此？

Docker 本身最擅長的是：

建立與執行 Container。

而 Kubernetes 更進一步處理：

Container Orchestration。

那 Docker Compose 呢？

這也是很好的問題。

Docker Compose 已經可以：

services:
  api:
  redis:
  postgres:

一次啟動多個服務。

所以小型開發環境：

Docker Compose

其實非常好用。

但是 Kubernetes 關心的範圍更大：

Multi-node Scheduling
Self-healing
Rolling Update
Autoscaling
Service Discovery
Persistent Storage
RBAC
NetworkPolicy
Cluster Management

因此不是：

Docker Compose 很爛
Kubernetes 比較厲害

而是：

它們解決的問題規模不同。

今天可以自己做一個超小實驗

如果電腦已經有 Docker：

docker run --name demo-nginx -d -p 8080:80 nginx

拆開來看。

docker run

建立並啟動 Container。

--name demo-nginx

幫 Container 命名。

-d

代表 Detached Mode，也就是背景執行。

-p 8080:80

表示：

你的電腦 8080
↓
Container 80

最後：

nginx

是使用的 Image。

現在：

docker ps

可以看到正在執行的 Container。

瀏覽：

http://localhost:8080

就能看到 nginx。

最後：

docker rm -f demo-nginx

刪掉。

Day 2 小結

今天真正要記住的不是 Docker 指令。

而是這條演進：

Physical Server
↓
Virtual Machine
↓
Container
↓
Container Orchestration
↓
Kubernetes

每一層其實都在解決上一層規模變大後出現的新問題。

明天我們正式打開 Kubernetes。

而且不會從 Pod 開始背。

我們先站到最高處，看懂整座 Kubernetes Cluster 到底有哪些角色。